『Out of the Tar Pit』

ソフトウェアは本質的に複雑だが、複雑さの種類があり、コントロールできる

2006/2/6

66ページある

著者

参考

解説

要点としては

まず、Complexityと呼んでいるものが、大きく分けて2つに分類できるということを意識すること

そして、残ったComplexity (Essentialと一部のAccidental)の依存関係を調整すること

Abstract

Brooksは、現代のComplexityの殆どがシステムの本質である、と前提しているが、それを批判する

1 Introduction

システムのComplexityの主な要因

状態

コード量

flow of control

OOPもFPも異なるアプローチをしてるが、各々様々な問題がある

OOP, FP, RDBのアイディアを組み合わせる

2 Complexity

複雑さ一般について

Compexity

Comformity

Changeability

Invisibility

あんまり何も言ってない

3 Approaches to Understanding

システムを理解するためのアプローチは2つある

Testing

システムをブラックボックスと捉え、外部から理解する

ある特定の状況でのシステムの振る舞いの結果を確認する

テストに依って達成できることには本質的な限界がある

特定のパターンしか見れないし

より多くのエラーを検出できる

Informal Reasoning

内部からシステムを調査し理解する

エラーの発生を減らすことができる

こちらの方が重要

「Informal」なので形式的なものではなく、経験や直観によるシステムの内部分析

ER図等を用いてアーキテクチャを理解する、みたいな感じだろうか

いずれにせよ、両方を併用しても限界があるのでシンプルにすべし、といった結論

4 Causes of Complexity

状態が引き起こす複雑さ

外部から見ても、内部から見ても辛い

前者はテストがつらいこと、後者は可読性が悪いことを言ってる

Controlが引き起こす複雑さ

順序は重要だが、常に必要なわけでもない

↓このようなコードがあるとき、各行は直交してるので並行に実行されても良い

しかし、このコードを読んだ人は、上から順に実行されることを期待する

code:_

a := b + 3

c := d + 2

e := f + 4

暗黙的に順序を強制される

コード量が引き起こす複雑さ

他の原因と比べて測定しやすい

他の原因と相互作用が大きい

その他

状態を許可するような言語を使う場合は常にそれに気を配る必要がある

5 Classical approasches to managing complexity

imperative, funcitona, logicでのアプローチ

OOP

状態

OOPのすべての形式は状態に依存しているので、状態に関する問題に悩まされる

複雑さを回避するための適切な基盤を提供できない

FP

状態

状態を完全に排除する言語だと、上述した複雑さの一つを完全に排除できる

Control

暗黙的な順序はあるものの、抽象的な制御を提供してるのでマシ

純粋関数はすべての引数を並列に評価できる

関数の引数を見るだけで制御されるものが分かる

Logical Programming

↑この辺は別に読まなくても良い感じだった

↓この辺からがおもしろポイント

6 Accidents and Essence

Brooksが「現代のComplexityの殆どがシステムの本質である」と前提していることに対する批判と深掘りをしている

Brooksを採用すると「複雑なんだ、しゃあないね」となってしまう

そうではなく、更にComplexityを大きく2つに分類した

したがって、こちら側をきる限り排除することでComplexityを小さくできる

7 Recommended General Approach

理想世界を考えて何がEssentialなのかを分析していく

理想世界には形式化すらない

コンピュータで動かすために最終的に形式が必要になるが、その過程で複雑さが増えないようなものであって欲しい

理想のインフラストラクチャで実行されることを想定する

It is interesting to note that effectively what we have just described is in fact the very essence of declarative programming - i.e. that you need only specify what you require, not how it must be achieved.

理想世界で、その状態が必要なのかどうかを考えて分類する

table:Data and State

Data Essentiality Data Type Data Mutability Classification

Essential Input - Essential State

Essential Derived Immutable Accidental State

Essential Derived Mutable Accidental State

Accidental Derived - Accidental State

例えば、ユーザが直接入力するデータはessentialだし、

キャッシュなど要件に含まれないものはAccidental

とにかく、Derivedして作られる状態はAccidental State

曰く、典型的なプログラムには多くのAccidental Stateが含まれており、それによって無駄に複雑化している

ControlはすべてAccidentalである

理想世界では全て0秒で完了する

確かにAccidentalなものは省略可能だが、そうすると表現が複雑になってしまうこともある

例えば、ユーザの位置は、初期開始位置とその後の動きから計算できるが、毎度それで計算するのもなあ、という感じ

パフォーマンスの問題もある

複雑さを処理するための推奨事項

避ける

分ける

table:Types of complexity within a system

Complexity Type Recommendation

Essential Logic Separate

Essential Complexity State Spearate

Accidental Useful Complexity State/Control Separate

Accidental Useful Complexity State/Control Avoid

8 The Relational Model

relational modelについて

9 Funcitional Relational Programming

10 Example of an FRP system

11 Related Work